Modify the wpf to connect to the mcp server using the stdio method #694
Conversation
… we are not using a console program, setting the input and output language of Console will have no effect and will throw an exception. For example, when using WPF, an exception will be thrown here, causing the connection to fail
…ding format for the console program if it is a console program
There was a problem hiding this comment.
Thanks for your contribution. It'd be great if we could unblock the usage of the stdio client in your WPF app.
How Has This Been Tested?
yes,i have tested in my wpf project
Can you file an issue with a link to the source code of a sample app (preferably a buildable github repo) that demonstrates the problem? This would help us test and verify different possible fixes.
| #if NET | ||
| processStarted = process.Start(); | ||
| #else |
There was a problem hiding this comment.
We should keep the simple #if NET (.NET Core) case which never sets Console.InputEncoding, so it cannot be the cause of your issues.
| } | ||
| #endif | ||
|
|
||
| processStarted = process.Start(); |
There was a problem hiding this comment.
We need start the process before resetting back to the originalInputEncoding for it to matter.
|
|
||
| private static bool HasConsole() | ||
| { | ||
| try { return GetConsoleWindow() != IntPtr.Zero; } catch { return false; } |
There was a problem hiding this comment.
I'm very suspicious this is the best way to determine whether the Console.InputEncoding setter is going to throw a NotSupportedException.
If we're going to catch arbitrary exceptions anyway, it would be better to catch the NotSupportedException from the setter although I'm not sure that's the best approach either. I think #73 added this logic. I'm curious if @willibrandon or @stephentoub have alternatives.
There was a problem hiding this comment.
If we're going to catch arbitrary exceptions anyway, it would be better to catch the NotSupportedException from the setter
Yeah, I'd rather just catch/eat the exception from the actual operation being performed than have a separate IsXx method that does the exact same thing and that's then used as a guard. We're about to launch a whole process; I'm not particularly concerned at the overhead of an exception.
That said, I'm unclear about the originally stated problem. I just created a WPF app, set both Console.OutputEncoding and Console.InputEncoding, and it worked fine, no exceptions. The code for these properties in Console also just bails without exception for what I would have expected in these cases:
https://github.com/dotnet/runtime/blob/edb570cd9e75036b6c61b201a0a9a9f2301db276/src/libraries/System.Console/src/System/ConsolePal.Windows.cs#L135-L138
Can you share a repro of the issue?
Hi maintainers 👋,
I've opened this PR to fix an issue where attempting to set
Console.InputEncodingandConsole.OutputEncodingin non-console applications (like WPF) throws aNotSupportedException, which causes the connection to the MCP server via stdio to fail.This change adds a check to detect whether the current environment supports console I/O before applying encoding settings, preventing the exception in GUI applications such as WPF.
✅ The fix has been tested locally in a real WPF application and resolves the connection issue.
✅ No breaking changes are introduced.
Could someone please review this when you have time? It would help enable smoother integration of the SDK in WPF and other desktop applications.
Thanks for your work on the project! 🙏
Modify the wpf to connect to the mcp server using the stdio method
Motivation and Context
WPF uses STDIO to connect to MCP server and throws an exception
How Has This Been Tested?
yes,i have tested in my wpf project
Breaking Changes
no
Types of changes
Checklist
Additional context